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The  basic  function  of  the  ARPA  computer  network  is  to  allow  large 
existing  computers  (Hosts),  with  different  system  configurations, 
to  communicate  with  each  other.  Each  Host  is  connected  to  an 
Interface  Message  Processor  (IF^P),  which  transmits  messages  from 
its  Host(s)  to  other  Hosts  and  accepts  messages  for  its  Host(s) 
from  other  Hosts.  There  is  frequently  no  direct  communication 
circuit  between  two  Hosts  that  v/ish  to  communicate;  in  these  cases 
intermediate  IMPs  act  as  message  sv/i  tchers .  The  message  sv/itching 
is  performed  as  a  store  and  forward  operation.  The  IMPs  regularly 
exchange  information  which:  allows  each  IF'^P  to  adapt  its  message 
routing  to  the  conditions  of  its  local  section  of  the  network; 
reports  network  performance  and  malfunct.-i ons  to  a  Network  Control 
Center;  permits  message  tracing  so  that  network  operation  can  be 
studied  comprehensively;  allows  network  reconfiguration  without 
reprogramming  each  IMP.  The  Terminal  IMP  (TIP),  which  consists 
of  an  IMP  and  a  Faulti-Line  Controller  (F^ILC),  extends  the  network 
concepts  by  permitting  the  direct  attachment  (without  an  intervening 
Host)  o.f  up  to  dissimilar  terminal  devices  to  the  network.  The 
Terminal  IMP  program  provides  many  aspects  of  the  Host  pi’otocols 
in  order  to  allow  effective  communication  between  a  terminal  user 
and  a  Host  process. 
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1.  OVERVIEW 

This  Quarterly  Technical  Report,  Number  15,  describes  the 
aspects  ,of  our  work  on  the  ARPA  computer  network  during  the  third 
quarter  of  1972. 

During  this  quarter,  th^ee  new  IMPs  were  installed  and  one 
was  relocated.  A  316  IMP  was  delivered  to  Aberdeen  Proving 
Grounds,  Aberdeen,  Maryland,  and  a  TIP  installed  at  Computer 
Corporation  of  America  (CCA),  Cambridge.  The  TIP  destined  for 
use  at  the  ICCC  show  was  temporarily  installed  in  another  section 
of  the  B3N  building  to  allow  rehearsal  of  the  scenarios  to  be 
presented  at  the  conference.  Tiie  316  IMP  at  McClellan  Air  Force 
Base  was  moved  to  Xerox  Palo  Alto  Research  Center  (PARC)  when 
McClellan  ceased  network  activities. 

During  the  third  quarter,  we  continued  tne  efforts  of  last 
quarter  to  bring  up  the  new  IMP/TIP  software.  An  operational 
system  v/as  released  early  in  the  quarter,  and  we  have  been  in¬ 
volved  in  promulgating  a  series  of  revisions  i:c  eliminate  the 
remaining  bugs  and  add  new  features.  Tuesday  mornings,  7:00- 
8:00  a.m..  Eastern  time,  have  been  publicly  declared  as  the  time 
set  aside  to  release  new  versions.  This  will  hopefully  allow  us 
t^  make  changes  in  the  system  with  a  minimum  of  interference  to 
network  users . 

The  new  system  also  incorporated  some  changes  to  the  IMP- 
Host  protocol.  VJr.ile  mia intaining,  for  the  most  part,  backwards 
compatibility,  existing  mes'-age  types  were  subdivided  to  allow 
more  precise  specifications  of  the  causes  of  errors  and  incom¬ 
plete  transmissions.  The  IMP  Going  Down  message  also  now 
specifies  the  reasons  for  same  and  how  soon  and  for  how  long 
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the  IMP  will  be  down.  A  new  message  indicating  an  interface 
reset  was  added.  Two  obsolete  message  types  were  deleted. 

We  have  also  engaged  in  a  series  of  experiments  to  test  and 
measure  the  efficiency  of  the  new  algorithms.  These  experiments 
have  not  been  completed,  but  have  already  i*aised  some  very  in¬ 
teresting  questions  about  the  system^ s  performance  and,  in  at 
least  one  case,  have  led  to  the  extermination  of  a  bug. 

We  have  developed  some  nev;  tools  for  preparing  and  document¬ 
ing  large  interrupt-driven  systems,  such  as  the  IMP  and  TIP.  The 
listings  output  by  these  processes,  by  explicitly  classifying  each 
instruction  or  data  wr rd  as  to  physical  and  virtual  interrupt 
level,  aid  in  debugging  and  have  the  potential  of  allowing  some 
algorithmic  (perhaps  automated)  program  verification. 

A  significant  portion  of  the  revisions  to  the  nevj  software 
has  concerned  whe  TIP  software.  A  new  protocol  for  the  magnetic 
tape  option  was  specified  and  implemented.  This  and  ether  work 
on  this  option  are  described  in  Section  2.  Major  efforts  were 
made  to  increase  communication  to  and  from,  the  users  of  the  TIP. 

A  revision  of  the  IMP/TIP  Operating  Manual  Report  No.  l877), 

two  revisions  of  the  TIP  User’s  Guide  (BBM  Report  No.  2183),  and 
a  new  document,  ’’Specifications  for  the  Intercom. ect ion  of 
Terminals  and  the  Terminal  IMP”  ( BBN  Report  No.  2277),  were 
issued.  Two  letters  detailing  new  features  and  oroposals  for 
more  of  the  same  were  distributed  to  che  network  community.  A 
new  command,  NEViS,  allows  users  dynamic  access  to  current  status 
via  facilities  of  BEN  Hosts.  Several  other  new  commands  v;ere 
implemented  and  the  logger  was  restructured.  The  internal  struc¬ 
ture  of  the  TIP  orogram  was  extensively  revised  to  clean  up  the 
interrupt  structure  and  reduce  interdependence  with  the  IMP 
program. 
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During  this  quarter,  we  have  continued  our  Investigations 
Into  the  methods  of  Implementing  communications  links  via 
satellite.  We  participated  in  a  meeting  on  satellite  techniques 
at  UCLA  and  have  contributed  several  papers  to  the  ARPANET 
Satellite  System  (ASS)  series.  We  have  investigated  through 
analysis  and  simulations  several  alternative  schemes  for  using  a 
satellite  channel  for  broadcast  communication.  Some  of  these 
proposals  are  discussed  in  Section  3. 

Another  major  continuing  effort  is  the  development  of  the 
HSMIMP.  With  the  selection  of  the  processor  and  the  gross  archi¬ 
tecture  firmly  established  (see  Section  3  of  our  Quarterly 
Techijical  Report  No.  14),  more  detailed  work  has  proceeded.  Four 
members  of  our  hardware  group  spent  considerable  time  at  Lockheed 
Electronics  Company  learning  the  detailed  characteristics  of  the 
SUE  system  and  fabricating  prototype  modules.  We  have  received 
the  initial  shipment  of  Lockheed  modules  for  our  prototype  sys¬ 
tems,  which  are  now  being  used  for  hardware  and  softv;are  de¬ 
bugging.  A  cross-assembler  for  the  SUE  machine  language  that 
runs  on  our  PDP-1  was  also  developed.  Specifications  for  many  of 
the  individual  BBN-designed  modules  have  been  established;  design 
and  (in  some  cases)  construction  are  in  progress.  At  the  same 
time,  we  have  been  very  concerned  with  broader  system  issues,  not 
only  those  dealir.g  with  making  an  efficient  and  reliable  multi¬ 
processor,  but  also  those  having  to  do  with  the  IMP/TIP  system 
and  subnet  as  a  whole.  Our  conception  of  the  HSMIMP  program 
organization  is  discussed  in  Section  4. 

We  have  also  continued  our  support  of  the  proposed  DCA 
Network.  A  new  member  of  our  group  has  teen  specifically  assigned 
to  serve  as  the  interface  to  DCA  and  has  been  assisting  with  the 
specification  of  the  Host  ’nterface  which  will  be  required  (for 
the  Honeywell  H-6000  ccmpu  jr)  as  well  as  with  other  implementation 
details . 
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Finally,  we  have  been  concerned  w.  th  preparations  for  the 
ICCC  show  In  October.  As  mentioned  above,  the  TIP  which  will  be 
on  display  was  made  available  for  checkout  and  practice  with  the 
various  terminals  which  will  be  used.  We  have  also  participated 
In  several  planning  meetings  and  will  be  sending  a  support  staff 
to  the  show. 
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2.  REVISION  OF  THE  TIP  MAGNETIC  TAPE  OPTION 

During  the  past  quarter,  it  was  decided  that  the  Initial 
Implementation  of  the  TIP  magnetic  tape  option  required  signifi¬ 
cant  revision  before  it  would  be  reliable.  Thus,  after  consulta¬ 
tion  with  the  ARPA  office  and  the  two  sites  having  the  option,  the 
magnetic  tape  option  was  temporarily  decommitted,  revised,  and 
rereleased . 

The  major  areas  of  revision  were  1)  to  the  TlP/ragnetlc  tape 
option  intex'face,  2)  to  the  magnetic  tape  drive  handling  routines, 
and  3)  to  the  cape  transfer  protocol. 

1)  The  TIP/magnetic  tape  option  interface  v,as  changed  so 
that  many  more  of  the  standard  TIP  mechanisms  could  be 
used  —  this  required  two  logical  TIP  ports  (62  and  63) 
to  be  dedicated  to  the  magnetic  tape  option.  However, 
this  change  simplified  the  interface  and  made  it  more 
reliable  since  more  of  it  is  standardly  used  on  all  TIP 
functions . 

2)  The  magnetic  tape  drive  handling  routines  were  simplified 
by  simplifying  the  record  buffering  algorithms. 

3)  The  tape  transfer  protocol  was  completely  rea^.na  as 
discussed  in  the  succeeding  paragraphs. 

By  the  time  it  was  decided  to  make  this  revision  of  the 
magnetic  tape  option,  the  proposed  file  transfer  protocol  origi¬ 
nally  adopted  by  the  TIP  tape  option  had  been  discarded  by  the 
Network  Working  Group.  Rather  than  wait  for  another  file  transfer 
protocol  to  be  decided  upon,  we  invented  what  we  have  called  the 
TIP  magnetic  tape  transfer  protocol.  This  protocol  has  the  dis¬ 
advantage  of  being  non-standard,  but  has  the  very  real  advantage 
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of  being  almost  trivial  to  implement  both  on  the  TIPs  and  on  any 
Host  wanting  to  communicate  with  a  TIP  mag  tape. 

The  magnetic  tape  protocol  is  as  follows: 

•  It  is  built  upon  the  Host/Host  protocol. 

•  A  record  is  an  integral  number  of  l6-bit  words  long. 

•  The  TIP  reading  a  magnetic  tape  presently  sends  no 
more  than  one  record  per  message,  although  a  record 
may  be  more  thaii  one  message  long. 

•  The  TIP  writing  a  magnetic  tape  can  receive  multiple 
record  messages.  Messages  of  records  received  by  the 
TIP  from  the  net  are  treated  as  a  stream  of  S-bit 
bytes  and  message  boundaries  can  occur  on  any  byte 
allowed  by  Kost/Host  protocol. 

•  The  message  format  requires  each  data  record  to  be 
precedea  b^  a  one-byte  code  (260g)  indicating  that 
the  ensuing  data  stream  (which  may  be  spread  over 
several  records)  is  a  magnetic  tape  record.  The 
code  is  followed  by  a  two-byte  count  of  the  number 

of  l6-bit  words  in  the  record.  Of  course,  each  message 
begins  with  the  usual  Host/Host  protocol  (which  is  not 
inclr.ded  in  the  count).  Each  record  is  terminated  by 
a  zero  byte. 

•  An  end  of  file  indicacion  is  sent  as  a  record  of 
length  zero,  i.e.,  the  mag  tape  code  byte  (260q),  a 
count  of  zero,  and  the  zero  byte  terminator, 

•  A  l6-bit  data  word  in  a  magnetic  tape  transfer  message 
currently  contains  two  6-bit  frames  of  tape,  each 
packed  in  the  lcv;-order  six  bits  of  a  byte.  Eventually, 
these  l6-lit  words  may  be  packed  full  for  greater 
efficiency . 
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Both  as  part  of  the  testing  process  and  also  to  help  make 
the  magnetic  tape  option  immediately  more  useful,  we  have  written 
a  simple  program  to  run  on  a  TENEX  system  to  copy  data  between 
TENEX  files  and  a  magnetic  tape  on  a  TIP.  This  program  is  avail¬ 
able  for  general  use,  but  we  do  not  intend  to  support  it. 
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3.  SATELLITE  TECHNIQUES 

In  preparation  for  the  incorporation  of  satellites  into  the 
ARPA  Network,  we  have  been  considering  techniques  for  using  a 
satellite  channel  in  a  way  which: 

1)  is  compatible  with  the  packet  switching  technology 
of  the  ARPA  Network, 

2)  is  highly  rel.able,  and 

3)  allows  high  utilization  of  the  channel  without 
subjecting  messages  to  too  large  a  delay. 

Ic  seems  clear  that  the  satellite  channel  should  be  a  broad¬ 
cast  channel  because  this  is  inherently  in  the  spirit  of  packet 
switcning.  A  broadcast  channel  v/ould  allow  the  commingling  of 
packets  for  different  destinations  on  the  same  channel,  therefore 
producing  a  more  efficient  uti  .ization  of  the  channel.  The 
techniques  for  governing  this  mixture  of  packets  include  Time 
Pivislon  Multiple  Access  (TDMA),  ALOHA,  various  reservation  sys- 
ter-s,  and  a  new  system  developed  at  3BN.  In  the  following  sec¬ 
tions  w“  will  discuss  each  of  these  techniques. 

3.1  TDMA 

TDMA  is  a  well-known  mechanism  for  allowing  many  nodes 
access  to  one  channel.  The  scheme  is  to  divide  time  into  cycles, 
with  the  cycles  subdivided  into  slots.  Each  node  is  allocated 
tne  same  slot  in  each  cycle.  Its  basic  disadvantage  is  that  the 
fraction  of  the  channel  which  is  available  to  one  node  is  in¬ 
versely  proportional  to  the  number  of  nodes  using  the  channel, 
rather  than  proportional  to  the  fraction  of  the  channel  which  is 
not  being  used. 


8 


Report  No.  2468 


Bolt  Beranek  and  Newman  Inc. 


3.2  ALOHA 

The  ALOHA  system  was  introduced  by  the  University  of  Hawaii. 

It  operates  in  this  way: 

1.  When  a  packet  is  ready  fo’^  transmission,  transmit  it. 

2.  If  you  do  not  receive  that  packet  at  the  appropriate 
time,  wait  for  a  random  length  of  time  (in  order  to 
avoid  recollision)  then  retransmit  it.  Then  go  to  2. 

The  ALOHA  system  is  a  simple  method  of  dynamically  allocating 
the  channel  without  centrali'^ed  control.  This  dynamic  allocation 
can  be  a  significant  improvement  over  the  fixed  allocation  of 
TDMA,  when  the  nodes  have  different  demands  on  the  channel. 

The  major  disadvantage  is  that  the  ALOHA  system,  as  described, 
has  a  cheoretical  capacity  of  only  .18,  and  a  corresponding  delay 
of  2.7  times  the  round  trip  time  to  the  satellite  at  capacity 
..n  order  to  improve  these  figures,  we  may  add  the  constraint  of 
starting  the  transmission  of  packets  only  at  discrete  time  inter¬ 
vals  (the  beginning  of  a  slot).  The  addition  of  this  constraint 
doubles  the  capacity  of  the  channel. 

The  average  delay  due  to  collisions  and  consequent  retrans¬ 
mission  experienced  by  a  packet  using  the  satellite  channel  with 
slots  is  a  function  of  the  traffic  on  the  channel.  V/hen  the 
throughput  is  one  tenth  to  one  fifth  of  the  channel,  the  average 
delay  is  very  nearly  one  round  trip  time.  Hov/ever,  as  the 
throughput  approaches  .36,  the  delay  rises  rapidly  to  2.7  times 
the  round  trip  time.  If  tne  e:round  stations  try  for  a  throughput 
greater  than  .36,  the  delay  -  icreases  greatly,  and  the  throughput 
decreases.  This  scheme  would  be  adequate  if  we  could  afford  to 
use  only  a  small  portion  of  the  channel. 
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3.3  Reservation  Systems 

Reservation  systems  are  those  in  which  some  slots  in  the 
channel  are  scheduled  on  the  basis  of  requests  by  the  nodes. 

These  requests  are  called  bids,  and  the  result  (if  successful)  is 
a  reservation.  In  the  systems  of  interest  to  us,  the  bids  are 
made  by  using  ALOHA  in  the  portion  of  the  channel  v/hich  is  not 
being  used  for  reservations,  or  by  using  the  current  reservation. 

The  basis  for  res ‘=‘rvation  systems  is  that  if  the  exact  time- 
varying  load  on  each  of  the  nodes  is  known,  it  should  be  possible 
to  schedule  the  channel  for  optimum  utilization  and  delay.  In 
theory,  this  scheduling  can  produce  a  channel  capacity  of  unity. 
There  are,  however,  several  problems. 

•  Any  system  which  requires  tight  scheduling  of  the 
channel  is  sensitive  to  perturbations  in  the  form  of 
line  errors  or  new  nodes.  If  a  bid  is  correctly 
received  by  all  nodes  but  one,  that  node  vj  1 1 1  have  an 
incorrect  idea  of  hov;  to  schedule  the  charine]  .  This 
problem  may  be  reduced  by  using  error  correction, 
etc.,  but  a  mechanism  v/ill  have  to  exist  to  reset 
everything  if  things  get  too  bad.  Furthermore, 

si  ce  a  new  node  would  have  no  inlormation,  it 
would  probably  have  to  force  a  reset. 

•  There  are  two  basic  reservation  strategies,  ore- 
dictive  and  riOr:-pre die t  i ve  .  In  a  non-preaict ive 
system,  one  w-il^s  until  a  packet  is  ready  for 
transrnissi  ri  before  making  a  reservation  for  it. 

This  al.LOWo  higher  throughput;  but  the  minimum 
delay  is  twice  the  rcund-trip  time.  V/e  have  done 
simulations  on  this. 
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In  a  predictive  system,  one  tries  to  anticipate  the  amount 
of  traffic  that  will  be  ready  for  transmission  at  the  time  that 
node’s  bid  is  honored.  The  difficulties  here  are: 

•  Each  node  must  keep  arrival  statistics  and  determine 
its  prediction.  This  costs  machine  bandwidth. 

•  When,  and  to  the  extent  that,  the  predictions  are 
wronf:;,  either  reserve'^  space  will  go  unused,  or 
surplus  packets  will  have  to  be  queued.  This 
problem  becomes  more  pronounced  if  the  source 
distribution  has  a  large  variance. 

We  expect  that  in  the  ARPA  Network,  the  routing 
mechods  employed  will  tend  to  smooth  the  traffic. 

•  /Iso,  a  node  is  forced  to  reserve  more  than  it 
expects  to  receive  to  avoid  the  problem  that 
occurs  wheii  a  queue  has  the  same  service  rate  as 
arrival  rate:  the  length  of  the  queue  is  in¬ 
determinate  and  all  traffic  would  be  delayed. 

This  trouble  was  experienced  in  the  ARPA  Network 
v/ith  an  earlier  ror  ing  algorithm. 

We  expect  that  the  sensitivity  of  reservation  systems  to 
perturbations  is  the  greatest  difficulty  v;ith  these  schemes;  it 
should  not  be  taken  too  lightly. 

3.4  BBN  ALOHA 

This  idea  is  a  variation  on  Reservation  schemes,  but  '"voids 
their  major  difficulty:  keeping  reservation  information  accurate. 
In  addition,  it  allows  the  steady-state  portion  of  a  n^ie’s 
traffic  to  pass  with  a  capacity  of  unity,  and  near  minimum  latency. 
It  allows  the  variable  portion  of  the  traffic  to  trade  delay  for 
bandwidth . 
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This  scheme  avoir's  the  basic  limiting  phenomenon  of  the 
ALOHA  system  (collisions)  in  a  straightforward  manner.  In  order 
to  decrease  the  probability  of  collision  for  a  packet,  each  node 
uses  the  slots  which  it  successfully  used  last  time  (whatever 
"last  time"  means).  The  probability  of  collision  will  be  signifi¬ 
cantly  lower  for  the  packets  which  use  those  slots. 

In  order  to  clarify  the  notion  of  "last  time",  here  is  an 
example  of  how  to  implement  this  system. 

Let  T  be  an  arbitrary  fixed  number  of  slots.  Let  each 
node  keep  a  history  of  slot  usage  for  the  past  T  slots; 
the  slots  which  are  en  route  over  tne  satellite  link  are 
included  in  T,  but  are  not  included  in  the  history  urr  il 
they  are  received. 

V/hen  a  node  has  a  packet  to  transmit,  it  should  try  to 
wait  for  a  slot  which  its  history  indicates  was  success¬ 
fully  used  by  that  node  T  slots  ago.  If  this  would 
cause  too  large  a  delay  or  too  small  a  throughput,  then 
wait  for  a  slct  which  was  empty  T  slots  ago. 

The  correct  value  of  T  probably  depends  on  time  constants  in  the 
network,  because  T  affects  the  response  time  of  this  channel. 

As  a  guideline,  T  should  probably  be  much  greater  than  the  number 
of  nodes.  ^erhaps  T  should  be  an  integral  multiple  of  the 
routing  period  so  that  routing  messages  alv;ays  use  the  same 
slots,  and  have  lov;  delay. 

We  nave  done  analysis  and  simulation  of  this  scheme  which 
verify  that  a  capacity  cf  unity  can  be  obtained  for  the  portion 
of  the  source  rate  which  is  constant. 
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There  were  two  difficulties  with  this  scheme: 

•  It  is  easier  to  lose  a  slot  than  to  gain  one.  This 
decreases  the  extent  to  which  the  variable  portion 
of  the  traffic  Is  smoothed,  and  decreases  the 
advantage  of  this  schem.e  when  used  with  sources  which 
have  a  large  variance. 

•  There  is  no  implicit  mechanism  for  ensuring  fairness 
in  utilization  of  the  channel.  The  big  guys  can 
squeeze  the  little  guys  out. 

The  first  of  these  difficulties  has  been  attacked  by  sending 
some  artificial  traffic  into  a  node’s  slots  when  they  would  other¬ 
wise  be  lo^t  due  to  a  temporary  lull  in  the  source  traffic.  This 
artificial  traffic  has  been  simulated  with  good  results,  using  a 
level  which  makes  it  as  difficult  to  lose  a  slot  as  it  Is  to  gain 
it  back. 

Fairness,  as  we  have  seen  in  the  rest  of  the  network,  has 
been  a  difficult  concept.  It  is  probably  best  approached  via  an 
exDlicit  algorithm  in  each  node.  A  possible  algorithm  would  have 
nodes  which  occupy  a  significant  portion  of  the  channel  avoid 
decreasing  the  fraction  of  empty  slots  beyond  a  certain  level, 
thus  providing  a  way  for  nodes  with  lighter  traffic  levels  to 
enter  the  channel. 

Conr*;  us  ions 

VJe  have  reached  the  conclusion  that  TDMA  and  Reservation 
schemes  are  probably  ill-suited  fc^r  use  in  this  environment.  vie 
believe  that  B3N  ALUHA  is  the  best  of  chese  schemes  for  TMP-IMP 
communication  via  satellite. 
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4.  HSMIMP  PROGRAM  UTILIZATION 

Classical  computers  rely  on  an  interrupt  structure  to  allow 
synchronization  of  real-time  events  with  a  minimum  of  overhead. 

The  important  ingredients  of  an  interrupt  system,  insofar  as  we 
are  concerned,  are  a  path  by  which  the  processor  can  be  notified 
to  divert  its  attention  and  a  mechanism  by  which  the  context 
(environment)  of  the  processor  can  be  remembered.  In  a  multi¬ 
processor  system,  the  former  is  complicated  not  only  by  the 
physical  distribution  of  the  processor  but  also  by  the  problem  of 
deciding  which  processor  should  handle  the  interrupt.  We  have 
also  observed  that  in  a  program  as  heavily  Interrupt  driven  as 
the  IMP,  14-15JS  of  the  machine  bandwidth  does  only  context  saving 
and  restoration.  This  is  particularly  painful  in  the  IMP  system 
wh'3re  one  can  find  very  many  places  in  which  there  is  no  context 
necessary  to  the  execution  of  the  next  step  (except  perhaps  the 
program  counter). 

To  overcome  these  disadvantages,  we  have  developed  a  different 
sort  of  program  organization  which  obviates  the  need  for  classical 
interrupts.  The  program  is  divided  into  "strips",  pieces  of  code 
which  take  less  than  200-300  ysec  to  execute  and  which  require  no 
processor  context  upon  entry.  The  stimulus  for  executing  a  strip 
is  usually  either  a  real-time  event  (e.g.,  I/O  completion)  or  a 
software  event  in  the  middle  of  another  strip.  Each  strip  is 
assigned  a  number. 

The  dispatch  of  processors  to  strips  is  handled  with  the  aid 
of  the  Pseudo-Interrupt  Device  (PID),  a  BBN-designed  module 
which  probably  resides  on  an  I/O  bus.  When  a  device  interface 
needs  service,  it  writes  the  number  of  the  strip  which  performs 
its  service  routine  to  the  PID.  Similarly,  when  a  processor 
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finishes  a  strip  which  is  logically  continued  in  another  strip, 
the  processor  writes  the  number  of  the  latter  to  the  PID.  V/hen 
a  processor  needs  a  new  task,  it  does  a  read  from  the  PID.  The 
PID  returns  the  highest,  number  written  to  it  but  not  yet  read, 
i.e.,  it  tells  the  processor  what  the  highest  priority  task  wait¬ 
ing  for  service  is  and  removes  that  task  from  the  list  of  those 
waiting.  The  processor  can  then  dispatch  to  the  appropriate 
routine  with  a  minimum  of  overhead  (2-355). 

Thus  we  have  avoided  the  difficulties  of  a  classical  interrupt 
system  while,  at  the  same  time,  solving  the  pi'oblem  of  task  assign¬ 
ment  to  processors.  By  imposing  a  maximum  on  strip  times,  we  can 
guarantee  that  the  lacency  before  the  service  routine  can  be 
started  for  the  highest  priority  task  is  no  greater  than  this 
maximum  time,  and  we  expect  the  average  time  to  be  tne  average 
strip  length  divided  by  the  number  of  processors.  This  must  be 
contrasted  with  the  context  saving  time  of  the  classical  system. 

On  the  other  hand,  we  are  spared  the  cost  of  a  more  traditional 
polling  scheme  since  the  PID  serves  as  a  central  clearing  house; 
a  processor  need  only  poll  in  one  place. 

This  program  structure  is  very  nicely  suited  tc  a  multi¬ 
processor.  Each  processor  can  and  generally  does  execute  all 
tasks,  thus  making  the  scheme  extremely  modular.  Task  assignment 
is  handled  in  a  simple,  generalized,  inexpensive  manner.  Without 
any  changes  to  the  program^  a  machine  may  be  configured  with  any 
number  of  processors  from  one  to  some  reasonable  number.  If  a 
processor  fails  (or  is  shut  down  for  maintenance)  in  a  multi¬ 
processor  HSMIMP,  the  machine  continues,  albeit  at  a  smaller 
bandwidth,  without  requiring  any  dynamic  reconfiguration  or  the 
like. 
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